Apparatus and method for installing and managing esim profiles

ABSTRACT

An apparatus and method for safely providing a profile to a terminal in a communication system are provided. The apparatus and method include a communication technique that combines a fifth generation (5G) communication system for supporting a data rate that is higher than that of a beyond fourth generation (4G) system with Internet of technology (IoT) technology, and a system thereof. The present disclosure may be applied to intelligent services based on 5G communication technology and IoT related technology, such as smart home, smart building, smart city, smart car or connected car, health care, digital education, retail, security and safety related services.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation application of prior application Ser.No. 15/825,995, filed on Nov. 29, 2017, which claimed the benefit under35 U.S.C. § 119(a) of a Korean patent application filed on Dec. 1, 2016in the Korean Intellectual Property Office and assigned Serial number10-2016-0162635, and of a Korean patent application filed on Apr. 26,2017 in the Korean Intellectual Property Office and assigned Serialnumber 10-2017-0053945, the entire disclosure of each of which is herebyincorporated by reference.

TECHNICAL FIELD

The present disclosure relates to an apparatus and a method forcommunication connection through downloading and installing acommunication service from a communication system to a terminal. Moreparticularly, the present disclosure relates to an apparatus and amethod for downloading, installing, and managing a profile online in acommunication system.

BACKGROUND

To meet the demand for wireless data traffic having increased sincedeployment of fourth generation (4G) communication systems, efforts havebeen made to develop an improved fifth generation (5G) or pre-5Gcommunication system. Therefore, the 5G or pre-5G communication systemis also called a ‘Beyond 4G Network’ or a ‘Post long-term evolution(LTE) System’. The 5G communication system is considered to beimplemented in higher frequency (mmWave) bands, e.g., 60 GHz bands, soas to accomplish higher data rates. To decrease propagation loss of theradio waves and increase the transmission distance, the beamforming,massive multiple-input multiple-output (MIMO), full dimensional MIMO(FD-MIMO), array antenna, an analog beam forming, large scale antennatechniques are discussed in 5G communication systems. In addition, in 5Gcommunication systems, development for system network improvement isunder way based on advanced small cells, cloud radio access networks(RANs), ultra-dense networks, device-to-device (D2D) communication,wireless backhaul, moving network, cooperative communication,coordinated multi-points (CoMP), reception-end interference cancellationand the like. In the 5G system, hybrid frequency shift keying (FSK) andquadrature amplitude modulation (QAM) modulation (FQAM) and slidingwindow superposition coding (SWSC) as an advanced coding modulation(ACM), and filter bank multi carrier (FBMC), non-orthogonal multipleaccess (NOMA), and sparse code multiple access (SCMA) as an advancedaccess technology have been developed.

The Internet, which is a human centered connectivity network wherehumans generate and consume information, is now evolving to the Internetof things (IoT) where distributed entities, such as things, exchange andprocess information without human intervention. The Internet ofeverything (IoE), which is a combination of the IoT technology and theBig Data processing technology through connection with a cloud server,has emerged. As technology elements, such as “sensing technology”,“wired/wireless communication and network infrastructure”, “serviceinterface technology”, and “Security technology” have been demanded forIoT implementation, a sensor network, a machine-to-machine (M2M)communication, machine type communication (MTC), and so forth have beenrecently researched. Such an IoT environment may provide intelligentInternet technology services that create a new value to human life bycollecting and analyzing data generated among connected things. IoT maybe applied to a variety of fields including smart home, smart building,smart city, smart car or connected cars, smart grid, health care, smartappliances and advanced medical services through convergence andcombination between existing information technology (IT) and variousindustrial applications.

In line with this, various attempts have been made to apply 5Gcommunication systems to IoT networks. For example, technologies such asa sensor network, MTC, and M2M communication may be implemented bybeamforming, MIMO, and array antennas. Application of a cloud RAN as theabove-described Big Data processing technology may also be considered tobe as an example of convergence between the 5G technology and the IoTtechnology.

A universal integrated circuit card (UICC) is a smart card used to beinserted into a mobile communication terminal or the like, and is calleda UICC card. The UICC may include an access control module for accessinga network of a mobile communication service provider. Examples of suchan access control module may be a universal subscriber identity module(USIM), a subscriber identity module (SIM), and an Internet protocol(IP) multimedia service identity module (ISIM). The UICC including theUSIM may be normally called the USIM card. In the same manner, the UICCincluding the SIM module may be normally called the SIM card. In thefollowing description of the present disclosure, the SIM card will benormally used to include the UICC card, the USIM card, and the UICCincluding the ISIM. That is, although the SIM card is mentioned, thetechnical characteristic thereof may also be applied to the USIM card,the ISIM card, or the general UICC card in the same manner.

The SIM card stores personal information of a mobile communicationsubscriber, and enables the subscriber to use safe mobile communicationsthrough performing subscriber authentication and traffic security keygeneration during accessing to a mobile communication network.

At the time of proposing the present disclosure, in general, the SIMcard is manufactured as a dedicated card for a specific mobilecommunication service provider by the request of the correspondingservice provider during manufacturing of the card, and authenticationinformation for accessing to the network of the corresponding serviceprovider, for example, a USIM application and international mobilesubscriber identity (IMSI), K value, and OPc value, is embedded inadvance in the card before shipping. Accordingly, the manufactured SIMcard is delivered to the corresponding mobile communication serviceprovider, and then is provided to the subscriber. Thereafter, if needed,management, such as installation, correction, and deletion, ofapplications in the UICC may be performed using technology, such asover-the-air (OTA). The subscriber can use the network and applicationservices of the corresponding mobile communication service providerthrough insertion of the UICC card into a subscriber's mobilecommunication terminal. In the case of replacement of the terminal, theUICC card may be removed from the existing terminal and then may beinserted into a new terminal, and thus it is possible to use theauthentication information, mobile communication phone number, personalphonebook, and the like stored in the UICC card as they are in the newterminal.

However, the SIM card is inconvenient in use in the case where a mobilecommunication terminal user intends to receive a service provided fromanother mobile communication service provider because the user shouldphysically acquire a SIM card for the service. For example, in the caseof making a trip to another country, the terminal user should purchase alocal SIM card in order to receive the local mobile communicationservice. Although a roaming service may somewhat address the problem ofinconvenience, the user may be unable to receive the service due toexpensive fees or nonexistent agreement between communication serviceproviders.

On the other hand, in the case where the SIM module is remotelydownloaded and installed in the UICC card, the problem of inconvenienceas described above can be considerably addressed. That is, the user candownload the SIM module of the mobile communication service intended tobe used into the UICC card at a desired time. A plurality of SIM modulesmay be downloaded and installed in the UICC card, and one of thedownloaded SIM modules may be selected to be used. The UICC card may beor may not be fixed to the terminal. In particular, the UICC fixed tothe terminal is called an embedded UICC (eUICC), and the eUICC means aUICC card which is normally fixed to the terminal and can remotelydownload and select the SIM module. In the present disclosure, the UICCcard capable of remotely downloading and selecting the SIM module iscommonly called the eUICC. That is, the UICC card that is fixed to or isnot fixed to the terminal among the UICC cards capable of remotelydownloading and selecting the SIM module is commonly called the eUICC.Further, downloaded SIM module information is commonly called an eUICCprofile.

The above information is presented as background information only toassist with an understanding of the present disclosure. No determinationhas been made, and no assertion is made, as to whether any of the abovemight be applicable as prior art with regard to the present disclosure.

SUMMARY

Aspects of the present disclosure are to address at least theabove-mentioned problems and/or disadvantages and to provide at leastthe advantages described below. Accordingly, an aspect of the presentdisclosure is to provide an apparatus and a method for a terminal toperform communication connection through selection of a communicationservice in a communication system.

Another aspect of the present disclosure is to provide an apparatus anda method for a terminal to download online, install, and manage aprofile for communication connection in a communication system.

Another aspect of the present disclosure is to provide an apparatus anda method for safely providing a profile to a terminal in a communicationsystem.

In particular, the present disclosure proposes a method for addressingthe followings for the above-described aspect.

-   -   Method for a terminal to transfer a message for requesting        profile download or remote profile management to a profile        management server subscription manger data preparation plus        (SM-DP+).    -   Method for a profile management server SM-DP+ to selectively        send profile download or remote profile management in reply to a        terminal and to send reference information to be used when the        terminal generates a message for requesting profile download or        remote profile management to be transferred to a next stage in        reply.    -   Message exchange procedure between the terminal and the profile        management server SM-DP+.

In accordance with an aspect of the present disclosure, a terminal in awireless communication system is provided. The terminal includes aninput unit (user interface) configured to display and receive an inputof a type of an event (profile download or remote profile management) tobe performed by the terminal from a user, a transmission unit capable oftransmitting to a profile management server SM-DP+ one or more ofembedded universal integrated circuit card (eUICC) identifier (EID) inthe terminal, EventRequestType indicating the type of an event to beperformed by the terminal, RPMConfig indicating whether the terminalpermits the remote profile management, integrated circuit card ID(ICCID) of a profile that is a subject for which the terminal is toperform the remote profile management, and OperatorID of a serviceprovider currently providing a communication service to the terminal, areception unit capable of receiving, in response to this, from theprofile management server SM-DP+ one or more events to be performed bythe terminal and one or more of the type and the number of one or moreevents to be performed by the terminal next time, an input unit (userinterface) configured to display to the user information on one or moreevents to be performed by the terminal, and to receive an input of auser consent to performing of the corresponding events, a processorconfigured to determine whether to proceed with or to stop performing ofone or more received events based on the input consent, a processorconfigured to perform the event if it is determined to proceed with theperforming of the event (i.e., if the user consent is input), aprocessor and a transmission unit configured to transmit the result ofperforming the event to the profile management server SM-DP+, and aprocessor and a transmission unit configured to transmit a message forrequesting a next event to the profile management server SM-DP+ inaccordance with the type and the number of the one or more events to beperformed by the terminal next time.

In accordance with another aspect of the present disclosure, a profilemanagement server SM-DP+ in a wireless communication system is provided.The profile management server SM-DP+ includes an event storageconfigured to store events (profile download or remote profilemanagement) to be performed by an eUICC of a terminal, a processor and adetermination unit configured to control and determine priorities of theevents stored in the event storage, a reception unit configured toreceive from the terminal one or more of EID in the terminal,EventRequestType indicating the type of the event to be performed by theterminal, RPMConfig indicating whether the terminal permits the remoteprofile management, ICCID of a profile that is a subject for which theterminal is to perform the remote profile management, and OperatorID ofa service provider currently providing a communication service to theterminal, a reception unit capable of receiving eUICC authenticationinformation including signature, a determination unit configured toselect one or more event to be performed by the terminal throughcomparison of the received message of the terminal with the prioritiesof the events stored in the event storage of the profile managementserver SM-DP+, a determination unit configured to grasp the type and thenumber of one or more events to be performed by the terminal next timeamong the events stored in the event storage, a transmission unitcapable of transmitting the type and the number of one or more events tobe performed by the terminal next time, a reception unit capable ofreceiving the result of performing the event from the terminal, and areception unit capable of receiving a message for requesting a nextevent from the terminal.

In accordance with another aspect of the present disclosure, a method bya terminal in a wireless communication system is provided. The methodincludes transmitting, to a server, a universal integrated circuit card(UICC) related message to request an event for the terminal, wherein theUICC related message includes information on an operation type of theevent, receiving, from the server, a response message including datacorresponding to the operation type, and performing an operation basedon the data.

In accordance with another aspect of the present disclosure, a terminalin a wireless communication system is provided. The terminal includes atransceiver and a processor coupled with the transceiver and configuredto control to transmit, to a server, a UICC related message to requestan event for the terminal, wherein the UICC related message includesinformation on an operation type of the event, receive, from the server,a response message including data corresponding to the operation type,and perform an operation based on the data.

In accordance with another aspect of the present disclosure, a method bya server in a wireless communication system is provided. The methodincludes receiving, from a terminal, a UICC related message to requestan event for the terminal, wherein the UICC related message includesinformation on an operation type of the event, and transmitting, to theterminal, a response message including data corresponding to theoperation type.

In accordance with another aspect of the present disclosure, a server ina wireless communication system is provided. The server includes atransceiver and a processor coupled with the transceiver and configuredto control to receive, from a terminal, a UICC related message torequest an event for the terminal, wherein the UICC related messageincludes information on an operation type of the event, and transmit, tothe terminal, a response message including data corresponding to theoperation type.

The technical aspects to be performed by the present disclosure are notlimited to those as described above, but other unmentioned aspects willbe clearly understood by those of ordinary skill in the art to which thepresent disclosure pertains from the following description.

In accordance with another aspect of the present disclosure, in thecommunication system, the terminal may notify the profile managementserver SM-DP+ of the current user's input, and selectively receive theevent to be currently performed among the profile download or the remoteprofile management from the profile management server SM-DP+, and theevent to be performed next time may be guided to the terminal. Throughthis, in the case where one or more events (profile download or remoteprofile management) are in a standby state in the profile managementserver SM-DP+, the terminal can automatically request, receive, and thenperform the next event.

Other aspects, advantages, and salient features of the disclosure willbecome apparent to those skilled in the art from the following detaileddescription, which, taken in conjunction with the annexed drawings,discloses various embodiments of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features, and advantages of certainembodiments of the present disclosure will be more apparent from thefollowing description taken in conjunction with the accompanyingdrawings, in which:

FIG. 1 is a diagram illustrating a method for a terminal to connect to amobile communication network using universal integrated circuit card(UICC) embedded with a fixed profile according to an embodiment of thepresent disclosure;

FIG. 2 is a diagram illustrating a message exchange procedure between aterminal and a profile server in the case of installing one or moreprofiles through a profile server according to an embodiment of thepresent disclosure

FIG. 3 is a diagram illustrating a message exchange procedure between aterminal and a profile server in the case where one or more profiles areinstalled through a profile server and one or more remote profilemanagements are performed according to an embodiment of the presentdisclosure;

FIG. 4 is a diagram illustrating a method for specifying the type of anevent corresponding to a command input by a user when a terminalrequests the event from a profile server according to an embodiment ofthe present disclosure;

FIG. 5 is a diagram illustrating a method for a profile server to managean event storage according to an embodiment of the present disclosure;

FIGS. 6A, 6B, 6C, and 6D are diagrams illustrating a method fordetermining whether a profile server can bind one or more events in abundle to perform bundle transmission according to an embodiment of thepresent disclosure;

FIGS. 7A, 7B, and 7C are diagrams illustrating a method for a profileserver to transfer an event to be currently performed when configuringan event response message according to an embodiment of the presentdisclosure;

FIG. 8 is a diagram illustrating a method for a profile server totransfer an event to be performed next time when configuring an eventresponse message according to an embodiment of the present disclosure;

FIG. 9 is a diagram illustrating a procedure for a profile server toconfigure an event response message according to an embodiment of thepresent disclosure;

FIGS. 10, 11, and 12 are diagrams illustrating a message procedure for aterminal and a profile server to successively receive and perform one ormore events according to an embodiment of the present disclosure;

FIG. 13 is a diagram illustrating a procedure in which a terminalrequests a “profile download” from a server and receives a response tothe request according to an embodiment of the present disclosure;

FIG. 14 is a diagram illustrating a procedure in which a terminalrequests a “remote profile management” from a server and receives aresponse to the request according to an embodiment of the presentdisclosure;

FIG. 15 is a diagram illustrating a procedure in which a terminalrequests all types of events from a server and receives a response tothe request according to an embodiment of the present disclosure;

FIG. 16 is a diagram illustrating a method for a terminal tosuccessively process events after preferentially securing data of allthe events according to an embodiment of the present disclosure;

FIG. 17 is a diagram illustrating a method for a terminal to secure andprocess data of respective events in the order of event receptionaccording to an embodiment of the present disclosure;

FIG. 18 is a diagram illustrating a method for a profile server togenerate and attach a separate signature to respective remote profilemanagement and profile metadata according to an embodiment of thepresent disclosure;

FIG. 19 is a diagram illustrating a method for a profile server tospecify the order of data processing while generating and attaching aseparate signature to respective remote profile management and profilemetadata according to an embodiment of the present disclosure;

FIG. 20 is a diagram illustrating a method for a profile server togenerate and attach a common signature to a part of respective remoteprofile management and profile metadata according to an embodiment ofthe present disclosure;

FIG. 21 is a diagram illustrating a method for a profile server tospecify the order of data processing while generating and attaching acommon signature to a part of respective remote profile management andprofile metadata according to an embodiment of the present disclosure;

FIGS. 22 and 23 are diagrams illustrating a signature generation anddata deployment method according to an embodiment of the presentdisclosure;

FIGS. 24A, 24B, 25, and 26 are diagrams illustrating a method forconfiguring a user interface (UI) in a terminal according to anembodiment of the present disclosure;

FIG. 27 is a diagram illustrating the operation of a terminal inaccordance with a time series flow according to an embodiment of thepresent disclosure;

FIG. 28 is a block diagram illustrating constituent elements of aterminal according to an embodiment of the present disclosure; and

FIG. 29 is a block diagram illustrating constituent elements of a serveraccording to an embodiment of the present disclosure.

Throughout the drawings, it should be noted that like reference numbersare used to depict the same or similar elements, features, andstructures.

DETAILED DESCRIPTION

The following description with reference to the accompanying drawings isprovided to assist in a comprehensive understanding of variousembodiments of the present disclosure as defined by the claims and theirequivalents. It includes various specific details to assist in thatunderstanding but these are to be regarded as merely exemplary.Accordingly, those of ordinary skill in the art will recognize thatvarious changes and modifications of the various embodiments describedherein can be made without departing from the scope and spirit of thepresent disclosure. In addition, descriptions of well-known functionsand constructions may be omitted for clarity and conciseness.

The terms and words used in the following description and claims are notlimited to the bibliographical meanings, but, are merely used by theinventor to enable a clear and consistent understanding of the presentdisclosure. Accordingly, it should be apparent to those skilled in theart that the following description of various embodiments of the presentdisclosure is provided for illustration purpose only and not for thepurpose of limiting the present disclosure as defined by the appendedclaims and their equivalents.

It is to be understood that the singular forms “a,” “an,” and “the”include plural referents unless the context clearly dictates otherwise.Thus, for example, reference to “a component surface” includes referenceto one or more of such surfaces.

In describing the various embodiments, explanation of the technicalcontents that are well-known in the technical fields to which thepresent disclosure pertains and are not directly related to the presentdisclosure will be omitted in the case where it is determined that theyobscure the subject matter of the present disclosure in unnecessarydetail.

For the same reason, in the accompanying drawings, some constituentelements are exaggerated, omitted, or roughly illustrated. Further,sizes of some constituent elements may not completely reflect the actualsizes thereof. In the drawings, the same drawing reference numerals areused for the same elements across various figures.

The aspects and features of the present disclosure and methods forachieving the aspects and features will be apparent by referring to thevarious embodiments to be described in detail with reference to theaccompanying drawings. However, the present disclosure is not limited tothe various embodiments disclosed hereinafter, but can be implemented indiverse forms. The matters defined in the description, such as thedetailed construction and elements, are nothing but specific detailsprovided to assist those of ordinary skill in the art in a comprehensiveunderstanding of the disclosure, and the present disclosure is onlydefined within the scope of the appended claims. In the entiredescription of the present disclosure, the same drawing referencenumerals are used for the same elements across various figures.

It will be understood that each block of the flowchart illustrations,and combinations of blocks in the flowchart illustrations, can beimplemented by computer program instructions. These computer programinstructions can be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing the functionsspecified in the flowchart block or blocks. These computer programinstructions may also be stored in a non-transitory computer-usable orcomputer-readable memory that can direct a computer or anotherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the non-transitorycomputer-usable or computer-readable memory produce an article ofmanufacture including instruction means that implement the functionspecified in the flowchart block or blocks. The computer programinstructions may also be loaded onto a computer or other programmabledata processing apparatus to cause a series of operational steps to beperformed on the computer or other programmable apparatus to produce acomputer implemented process such that the instructions that execute onthe computer or other programmable apparatus provide steps forimplementing the functions specified in the flowchart block or blocks.

Also, each block of the flowchart illustrations may represent a module,segment, or portion of code, which comprises one or more executableinstructions for implementing the specified logical function(s). Itshould also be noted that in some alternative implementations, thefunctions noted in the blocks may occur out of the order. For example,two blocks shown in succession may in fact be executed substantiallyconcurrently or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved.

The term “unit”, as used in an embodiment, means, but is not limited to,a software or hardware component, such as FPGA or ASIC, which performscertain tasks. However, “unit” does not mean to be limited to softwareor hardware. The term “˜unit” may advantageously be configured to resideon the addressable storage medium and configured to execute on one ormore processors. Thus, “unit” may include, by way of example,components, such as software components, object-oriented softwarecomponents, class components and task components, processes, functions,attributes, procedures, subroutines, segments of program code, drivers,firmware, microcode, circuitry, data, databases, data structures,tables, arrays, and variables. The functionality provided for in thecomponents and “units” may be combined into fewer components and “units”or further separated into additional components and “units”. Further,the components and “units” may be implemented to operate one or moreCPUs in a device or a security multimedia card.

Specific terms used in the following description are provided to helpunderstanding of the present disclosure, and may be modified indifferent forms within a range that does not deviate from the technicalidea of the present disclosure.

First, terms used in the description will be defined.

In the description, a universal integrated circuit card (UICC) is asmart card used to be inserted into a mobile communication terminal, andmeans a chip which stores therein personal information, such as networkaccess authentication information of a mobile communication subscriber,phonebook, and short message service (SMS), and can safely use themobile communication by performing subscriber authentication and trafficsecurity key generation when accessing a mobile communication network,such as global satellite movement (GSM), wideband code division multipleaccess (WCDMA), and long-term evolution (LTE). In the UICC,communication applications, such as subscriber identification module(SIM), universal SIM (USIM), and Internet protocol (IP) multimedia SIM(ISIM), are embedded in accordance with the type of the mobilecommunication network accessed by the subscriber, and the UICC mayprovide an upper-level security function for embedding of variousapplication programs, such as e-wallet, ticketing, and e-passport.

In the description, an embedded UICC (eUICC) is a chip type securitymodule embedded in the terminal other than a detachable type that can beinserted into or detached from the terminal. The eUICC may download andinstall a profile using over-the-air (OTA) technique. The eUICC may becalled a UICC in which profile download and installation can beperformed.

In the description, a method for downloading and installing a profile inthe eUICC using the OTA technique may be applied to a detachable typeUICC that can be inserted into or detached from the terminal. That is,an embodiment of the present disclosure may be applied to the UICCcapable of downloading and installing a profile using the OTA technique.

In the description, the term “UICC” may be mixedly used with SIM, andthe term “eUICC” may be mixedly used with eSIM.

In the description, the profile may mean packaging of an application, afile system, and an authentication key value stored in the UICC in theform of software.

In the description, the USIM profile may have the same meaning as theprofile, or may mean packaging of information included in the USIMapplication in the profile in the form of software.

In the description, a profile providing server may include a function ofgenerating a profile, encrypting the generated profile, generating aremote profile management command, or encrypting the generated remoteprofile management command, and may be expressed as a subscriptionmanager data preparation (SM-DP), a subscription manger data preparationplus (SM-DP+), an off-card entity of profile domain, a profileencryption server, a profile generation server, a profile provisioner(PP), a profile provider, or a profile provisioning credentials holder(PPC holder).

In the description, the profile management server may be expressed as asubscription manager secure routing (SM-SR), a subscription mangersecure routing plus (SM-SR+), an off-card entity of eUICC profilemanager, a profile management credentials holder (PMC holder), or aneUICC manager (EM).

In the present description, the profile providing server may be commonlycalled as the profile providing server to which a function of theprofile management server is added. Accordingly, in various embodimentsof the present disclosure, that is, in beyond technology, it is alsopossible that the operation of the profile providing server is performedby the profile management server. In the same manner, it is alsopossible the operation described with respect to the profile managementserver or SM-SR may be performed by the profile providing server.

The term “terminal” used in the description may be called a mobilestation (MS), user equipment (UE), user terminal (UT), wirelessterminal, access terminal (AT), terminal, subscriber unit, subscriberstation (SS), wireless device, wireless communication device, wirelesstransmit/receive unit (WTRU), moving node, mobile, or other terms.Various embodiments of the terminal may include a cellular phone, asmart phone having a wireless communication function, a personal digitalassistant (PDA), wireless modem, a portable computer having a wirelesscommunication function, an imaging device, such as a digital camerahaving a wireless communication function, a gaming device having awireless communication function, a music storage and reproduction homeappliance having a wireless communication function, an Internet homeappliance capable of wireless Internet connection and browsing, aportable unit or terminal integrating combinations of such functions.Further, the terminal may include a machine to machine (M2M) terminal,or machine type communication (MTC) terminal/device, but is not limitedthereto. In the description, the terminal may be called an electronicdevice.

In the description, a UICC capable of downloading and installing aprofile may be embedded in the electronic device. If the UICC is notembedded in the electronic device, the UICC that is physically separatedfrom the electronic device may be inserted into the electronic device tobe connected to the electronic device. For example, the card type UICCmay be inserted into the electronic device. The electronic device mayinclude the terminal, and in this case, the terminal may be a terminalincluding the UICC capable of downloading and installing a profile. TheUICC may be embedded in the terminal, and if the terminal and the UICCare separated from each other, the UICC may be inserted into theterminal to be connected to the terminal. The UICC capable ofdownloading and installing a profile may be called, for example, aneUICC.

In the description, the terminal or the electronic device may includesoftware or an application installed in the terminal or the electronicdevice to control the UICC or eUICC. The software or the application maybe called, for example, a local profile assistant (LPA).

In the description, a profile discriminator may be called a profile ID,an integrated circuit card ID (ICCID), a machine ID, an event ID, anactivation code, an activation code token, ISD-P or a factor matching aprofile domain (PD). The profile ID may indicate an inherent identifierof each profile. The profile discriminator may include an address of aprofile providing server (SM-DP+) capable of indexing the profile.

In the description, the eUICC ID may be an inherent identifier of theeUICC embedded in the terminal, and may be called an eUICC identifier(EID). Further, if a provisioning profile has already been embedded inthe eUICC, it may be a profile ID of the corresponding provisioningprofile. Further, in an embodiment of the present disclosure, if theterminal and the eUICC chip are not separated from each other, it may bea terminal ID. Further, it may be called a specific secure domain of theeUICC chip.

In the description, a profile container may be called a profile domain.The profile container may be a security domain.

In the description, an application protocol data unit (APDU) may be amessage for the terminal to interlock with the eUICC. Further, the APDUmay be a message for a PP or PM to interlock with the eUICC.

In the description, PPC may be a mean used to perform mutualauthentication between the profile providing server and the eUICC,profile encryption, and signature. The PPC may include one or more of asymmetric key, a Rivest Shamir Adleman (RSA) certificate and a privatekey, an elliptic curved cryptography (ECC) certificate and a privatekey, a root certification authority (CA), and a certificate chain.Further, if a plurality of profile providing servers are provided,different PPCs for the plurality of profile providing servers may bestored in the eUICC or may be used.

In the description, PMC may be a mean used to perform mutualauthentication between the profile management server and the eUICC,transmitted data encryption, and signature. The PMC may include one ormore of a symmetric key, an RSA certificate and a private key, an ECCcertificate and a private key, a root CA, and a certificate chain.Further, if a plurality of profile management servers are provided,different PMCs for the plurality of profile management servers may bestored in the eUICC or may be used.

In the description, an application identifier (AID) may be referred to.This value may be a discriminator for discriminating between differentapplications in the eUICC.

In the description, an event may be a term commonly calling profiledownload, remote profile management, or other profile or eUICCmanagement/processing command. The profile download may be mixedly usedwith profile installation. Further, the event type may be used as a termindicating whether a specific event is profile download or remoteprofile management or whether it is other profile or eUICCmanagement/processing command, and the event type may be called anoperation type (or OperationType), an operation class (orOperationClass), an event request type, an event class, or an eventrequest class.

In the description, a profile package may be mixedly used with aprofile, or may be used as a term indicating a data object of a specificprofile, and the profile package may be called a profile TLV or profilepackage TLV. If the profile package is encrypted using an encryptionparameter, it may be called a protected profile package (PPP) or aprotected profile package TLV (PPP TLV). If the profile package isencrypted using an encryption parameter that can be decrypted only by aspecific eUICC, it may be called a bound profile package (BPP) or abound profile package TLV (BPP TLV). The profile package TLV may be adata set expressing information that constitutes a profile in a tag,length, and value (TLV) type.

In the description, the remote profile management (RPM) may be called aprofile remote management, remote management, remote management command,remote command, RPM package, profile remote management package, remotemanagement package, remote management command package, or remote commandpackage. The RPM may be used to change the state (enabled, disabled, ordeleted) of a specific profile or to update the contents of a specificprofile (e.g., profile nickname or profile metadata). The RPM mayinclude one or more remote management commands, and in this case, theprofiles that are the subjects of the respective remote managementcommands may be equal to or may be different from each other.

In the description, AKA may indicate authentication and key agreement,and may indicate an authentication algorithm for accessing to 3rdgeneration partnership project (3 GPP) and 3GPP2 networks.

In the description, K is an encryption key value stored in the eUICCused for an AKA authentication algorithm.

In the description, OPc is a parameter value that can be stored in theeUICC used for the AKA authentication algorithm.

In the description, NAA is a network access application program, and maybe an application program, such as USIM or ISIM, stored in the UICC toaccess the network. The NAA may be a network access module.

Further, in describing the present disclosure, a detailed description ofrelated known functions or configurations will be omitted if it isdetermined that it obscures the subject matter of the present disclosurein unnecessary detail.

FIG. 1 is a diagram illustrating a method for a terminal to connect to amobile communication network using UICC embedded with a profile fixed tothe terminal according to an embodiment of the present disclosure.

Referring to FIG. 1, a UICC 120 may be inserted into a terminal 110. Inthis case, the UICC may be of a detachable type, or may be pre-embeddedin the terminal. The fixed profile of the UICC embedded with the fixedprofile means that “access information” capable of accessing to aspecific communication service provider is fixed. The access informationmay be, for example, the international mobile subscriber identity (IMSI)that is the subscriber discriminator and a K or Ki value that is usedfor authentication in the network together with the subscriberdiscriminator.

Then, the terminal may perform authentication with an authenticationprocessing system (e.g., home location register (HLR) or AuC) of amobile communication service provider using the UICC. The authenticationprocess may be an authentication and key agreement (AKA) process. If theauthentication has succeeded, the terminal may then use a mobilecommunication service, such as phone call or use of mobile data, using amobile communication service provider network 130 of the mobilecommunication system.

Hereafter, reference will be made to a terminal 230 and a profile server250. The terminal 230 may be the terminal 110. The terminal 230 mayinclude at least one of an LPA or an eUICC. The profile server 250 mayinclude an SM-DP+.

FIG. 2 is a diagram illustrating a message exchange procedure between aterminal 230 and a profile server 250 in the case of installing one ormore profiles through the profile server according to an embodiment ofthe present disclosure.

Referring to FIG. 2, at operation 201, the terminal 230 may receive an“add profile” command from a user, and at operation 203, it may performTLS connection and mutual authentication with the profile server 250. Atoperation 205, the terminal may transfer to the profile server 250 anEID of the terminal as the final procedure of the mutual authenticationprocedure. At operation 207, the profile server may confirm a list ofevents to be installed in the corresponding terminal through the EID. Atoperation 209, the profile server may select an event having the highestpriority (in this embodiment, profile 1 installation) among the eventsin the list. At operation 211, the profile server may send metadata ofthe selected profile to the terminal in replay. At operation 213, theterminal may obtain user consent to the profile installation throughillustration of the metadata of the profile to the user. At operation215, the terminal may transfer the user consent to the profile serverand may receive a profile package. At operation 217, the terminal maysuccessfully install the profile package, and at operation 219, it maytransfer the result to the profile server.

According to the profile package installation procedure, if one or moreevents are in a standby state in the profile server, it is not possibleto notify the terminal that further events in the standby state remainin the profile server after performing and processing a specific event.In addition, in order to install one or more profiles, the user shouldinput an “add profile” command to the terminal to cause inconvenience.

FIG. 3 is a diagram illustrating a message exchange procedure between aterminal 230 and a profile server 250 in the case where one or moreprofiles are installed through the profile server and one or more remoteprofile managements are performed according to an embodiment of thepresent disclosure.

Referring to FIG. 3, at operation 301, the terminal 230 may receive an“add profile” command from a user, and at operation 303, it may performTLS connection and mutual authentication with the profile server 250. Atoperation 305, the terminal may transfer to the profile server 250 anEID of the terminal as the final procedure of the mutual authenticationprocedure. At operation 307, the profile server may confirm a list ofevents (profile or remote management) to be installed in thecorresponding terminal through the EID. At operation 309, the profileserver may select an event having the highest priority (in thisembodiment, remote management 1) among the events in the list. Atoperation 311, the profile server may send the selected remotemanagement command to the terminal in replay. At operation 313, theterminal may perform the received remote management command. Atoperation 315, the terminal may transfer the result of performing theremote management command to the profile server.

According to the profile installation and remote management performingprocedure, if one or more events are in a standby state in the profileserver, it is not possible to notify the terminal that further events inthe standby state remain in the profile server after performing andprocessing a specific event. In addition, although the user has inputthe “add profile” command to the terminal at operation 301, the terminalpreferentially receives the remote management command that is the eventhaving the highest priority from the profile server, and performs anoperation that is against the user's intention to cause confusion to theuser.

FIG. 4 is a diagram illustrating a method for specifying the type of anevent corresponding to a command input by a user when a terminal 230requests the event from a profile server 250 according to an embodimentof the present disclosure. Although case 1, case 2, and case 3 of FIG. 4illustrate respective independent embodiments, two or more cases may besuccessively performed.

Referring to FIG. 4, at operation 401, the terminal may receive an “addprofile” command from a user. At operation 403, the terminal maycomplete TLS secure connection and mutual authentication with theprofile server with respect to the user input, and may request an eventfrom the profile server 250 by specifying the event type correspondingto the profile download. In this case, the event type may be displayedas a text (in this embodiment, “ProfileDownload”) or as one value of thecorresponding enumerate. For example, if the enumerate values “0, 1”correspond to the “profile download” and “remote profile management”,the numeral “0” may be used instead of the text “ProfileDownload”.Further, at operation 403, the terminal may notify the profile serverwhether the user currently activates (on) the remote profile managementfunction of the terminal, or may notify of the service provider'sidentifier (OperatorID) that is currently providing the communicationservice to the corresponding terminal. At operation 405, the profileserver may select a profile installation event having high priority inaccordance with the terminal's request. A method for the profile serverto use the event type, profile management functionactivation/inactivation, and service provider identifier information anda method for managing the priority of an event will be described indetail according to an embodiment to be described later.

Further, referring to FIG. 4, at operation 407, the terminal may receivea “refresh profile” command from a user. At operation 409, the terminalmay complete TLS secure connection and mutual authentication with theprofile server with respect to the user input, and may request an eventfrom the profile server 250 by specifying the event type correspondingto the remote profile management. In this case, the event type may bedisplayed as a text (in this embodiment, “RPM”) or as one value of thecorresponding enumerate. For example, if the enumerate values “0, 1”correspond to the “profile download” and “remote profile management”,the numeral “1” may be used instead of the text “RPM”. Further, atoperation 409, the terminal may notify the profile server whether theuser currently activates (on) the remote profile management function ofthe terminal, or may notify of the service provider's identifier(OperatorID) that is currently providing the communication service tothe corresponding terminal. At operation 411, the profile server mayselect a remote profile management event having high priority inaccordance with the terminal's request. A method for the profile serverto use the event type, profile management functionactivation/inactivation, and service provider identifier information anda method for managing the priority of an event will be described indetail according to an embodiment to be described later.

Further, referring to FIG. 4, at operation 413, the terminal may receivean “update all” command from a user. At operation 4015, the terminal maycomplete TLS secure connection and mutual authentication with theprofile server with respect to the user input, and may request an eventfrom the profile server 250 by specifying the event type correspondingto the profile download and the remote profile management. In this case,the event type may be displayed as a text (in this embodiment, “ANY”) oras one or more values of the corresponding enumerate, or throughcomposite application of the method used in the embodiment of theprofile download or the remote profile management. For example, a text“ProfileDownload, RPM” may be used instead of the text “ANY”, or if theenumerate values “0, 1, 2” correspond to the “profile download”, “remoteprofile management”, and “update all”, the numeral “2” may be used orthe enumerate values “0, 1” may be used. Further, at operation 415, theterminal may notify the profile server whether the user currentlyactivates (on) the remote profile management function of the terminal,or may notify of the service provider's identifier (OperatorID) that iscurrently providing the communication service to the correspondingterminal. At operation 417, the profile server may select an event(profile download or remote profile management) having high priority inaccordance with the terminal's request. A method for the profile serverto use the event type, profile management functionactivation/inactivation, and service provider identifier information anda method for managing the priority of an event will be described indetail according to an embodiment to be described later.

FIG. 5 is a diagram illustrating a method for a profile server to managean event storage according to an embodiment of the present disclosure.

Referring to FIG. 5, a profile server may manage an event storage thatis discriminated as an EID. In each event storage, one or more events(profile download or remote profile management) to be performed by thecorresponding eUICC (or terminal) may be stored. Further, the eventsstored in the respective event storages may have their priorities, and amethod for calculating the priority may follow one or more compositemethods as follows, but the events are not limited to the list below.

-   -   The order of event registration in an event storage.    -   Priority value allocated when a service provider registers an        event.    -   Event type (e.g., profile download may have a priority that is        higher than the priority of remote profile management).    -   Priority value optionally determined and allocated by a profile        server.

If one or more events have the same priority, the profile server mayalign the corresponding events in a certain order. In an embodiment ofthe present disclosure, it is exemplified that the priority of the eventis managed in first-in first-out (FIFO) type in accordance with theorder of event registration in the event storage. However, it is to benoted that the priority of the event may be calculated in variousmethods as described above.

FIGS. 6A, 6B, 6C, and 6D are diagrams illustrating a method fordetermining whether a profile server can bind a plurality of events inone message to perform bundle transmission in the case where a profileserver transmits one or more events to the terminal according to anembodiment of the present disclosure.

Referring to FIGS. 6A, 6B, 6C, and 6D, the profile server may manage atable for determining whether it is possible to bind a specific eventtype with another event type for each event type to perform bundletransmission.

Referring to FIG. 6A, the profile server may determine to bind allevents to perform bundle transmission regardless of the event type.

Referring to FIG. 6B, the profile server may be set to permit onlybinding of remote profile management events to perform bundletransmission, but may be set not to permit binding of profile downloadevents or binding of a profile download event and a remote profilemanagement event to perform bundle transmission.

Referring to FIG. 6C, the profile server may be set to permit onlybinding of the remote profile management event and the profile downloadevent to perform bundle transmission, but may be set not to permitbinding of profile download events or not to permit binding of remoteprofile management events to perform bundle transmission.

Referring to FIG. 6D, the profile server may not permit binding of anyevents to perform bundle transmission.

In this embodiment, two types of events are exemplified, but asdescribed above, if the number of event types is increased to three ormore, the size of the table may also be increased accordingly. Further,determination of the event types to be transmitted in a bundle is notlimited to those as illustrated in FIGS. 6A, 6B, 6C, and 6D, and it maydiffer depending on combination of the events to be transmitted in abundle.

FIGS. 7A, 7B, and 7C are diagrams illustrating a method for a profileserver to configure information of “current events” when the profileserver configures a response message to an event request message of aterminal including the “current events” to be currently processed by theterminal and “next events” in a standby state in an event storageaccording to an embodiment of the present disclosure.

Referring to FIGS. 7A, 7B, and 7C, at operations 701A, 701B, and 701C,the terminal 230 may transmit an event request message to the profileserver 250. The configuration and detailed explanation of the eventrequest message have been made with reference to the embodiment of FIG.4. With respect to the event request message of the terminal, theprofile server, at operations 703A, 703B, and 703C, may configure anevent response message using information on one or more “current events”selected from the event storage in accordance with the priority andevents remaining in the event storage excluding the current events. Inthis case, selection of the current events may be performed as followsin accordance with the event type specified in the event request messageof the terminal, event storage state of the profile server, and whetherto permit preferential transmission.

The profile server may manage a priority setup table for permittingwhether an event of a low priority can be transmitted to the terminalprior to an event of a high priority in accordance with the respectiveevent types.

Referring to FIG. 7B, if the terminal requests, the profile downloadevent may be set to be preferentially transmitted to the terminal evenif the profile download event has a priority that is lower than thepriority of the remote profile management event, whereas the remoteprofile management event may be set not to be preferentially transmittedto the terminal in response to the terminal's request if the remoteprofile management event has a priority that is lower than the priorityof the profile download event. In this case, if the terminalspecifically requests the profile download event in a state where theevent priorities in the event storage are aligned in the order as in theembodiment of the profile server 250, a profile download event Profile1corresponding to the third priority may be selected more preferentiallythan remote profile management events RPM1 and RPM2 corresponding to thefirst and second priorities, and may be transmitted to the terminalthrough a “current event” field. In this case, the residual events RPM1,RPM2, RPM3, and Profile2 may be included in the “next events” to betransmitted to the terminal 230 according to an embodiment of FIG. 8 tobe described later.

Referring to FIG. 7C, except for the priority of the event, it may beset that any event is unable to be transmitted more preferentially thanother events. In this case, even if the terminal specifically requeststhe profile download event in a state where the event priorities in theevent storage are aligned in the order as in the embodiment of theprofile server 250, the remote profile management event RPM1 that hasthe highest priority should be preferentially performed, and the“current event” field becomes empty, and thus no event may betransmitted to the terminal. In this case, the residual events RPM1,RPM2, Profile1, RPM3, and Profile2 may be included in the “next events”to be transmitted according to an embodiment of FIG. 8 to be describedlater.

In the various embodiments of FIGS. 7A, 7B, and 7C, only one “currentevent” is selected in accordance with the preferential transmissionsetup, but it is to be noted that one or more events may be selected asdescribed above as in the embodiment of FIGS. 6A, 6B, 6C, and 6D. Forexample, if bundle transmission of the profile download events is set tobe possible as in the embodiment of FIG. 6A in addition to theembodiment of FIG. 7B, at operation 703B of FIG. 7B, two profiledownload events Profile1 and Profile2 may be simultaneously included inthe “current events” field to be transmitted to the terminal 230.

FIG. 8 is a diagram illustrating a diagram illustrating a method for aprofile server to configure information of “next events” when theprofile server configures a response message to an event request messageof a terminal including the “current events” to be currently processedby the terminal and “next events” in a standby state in an event storageaccording to an embodiment of the present disclosure.

Referring to FIG. 8, at operation 801, the terminal 230 may transmit anevent request message to the profile server 250. The configuration anddetailed explanation of the event request message have been made withreference to the embodiment of FIG. 4. With respect to the event requestmessage of the terminal, the profile server, at operation 803, mayconfigure an event response message using information on one or more“current events” selected from the event storage in accordance with thepriority and events remaining in the event storage excluding the currentevents. In this embodiment, as selection of the current events, a casewhere one remote management event RPM1 is selected to suit the requestof the terminal is illustrated. However, as in the embodiment of FIGS.6A, 6B, 6C, and 6D, one or more events may be selected in accordancewith whether the profile server can perform bundle transmission, and asin the embodiment of FIGS. 7A, 7B, and 7C, it is to be noted that theevent type specified in the event request message of the terminal may besearched for from the event storage, and the corresponding event may betransmitted more preferentially than the event having the highestpriority. Further, next event information may be compositely configuredusing one or more information elements as follows, but the usableinformation elements are not limited thereto.

-   -   Event type of an event having highest priority among residual        events.    -   Event type of one or more residual events.    -   Existence/nonexistence of one or more residual events.    -   The number of event types when the residual events are        classified by event types.

As an example, in an embodiment of FIG. 8, in the case of sending onlythe event type of the event having the highest priority in replay, anevent response message may be configured as follows.

-   -   Current Events=RPM1, Next Events=“RPM”.

As another example, in an embodiment of FIG. 8, in the case of sendingthe event types of all remaining events in replay, an event responsemessage may be configured as follows.

-   -   Current Events=RPM1, Next Events=“RPM”, ProfileDownload, RPM,        ProfileDownload“.

As still another example, in an embodiment of FIG. 8, in the case ofsending the number of event types in reply through classification of theresidual events by event types, an event response message may beconfigured as follows.

-   -   Current Events=RPM1, Next Events=“RPM (2), ProfileDownload (2)”.

As yet still another example, in an embodiment of FIG. 8, in the case ofreplying that one or more residual events remain regardless of the eventtype, an event response message may be configured as follows.

-   -   Current Events=RPM1, Next Events=TRUE.

In the above embodiment, the event type is displayed using a text (“RPM”or “ProfileDownload”). However, as described above as in the embodimentof FIG. 4, enumeration may also be used in addition to the text.Further, in the case of notifying the terminal that one or more eventsexist regardless of the event type, a binary recognizer (Boolean) havingtrue/false instead of the text or enumerate may be used.

FIG. 9 is a diagram illustrating a procedure for a profile server toconfigure an event response message to an event request message of aterminal with reference to the event bundle transmission and the eventpreferential transmission setup as described in the various embodimentsof FIGS. 6A, 6B, 6C, 6D, 7A, 7B, 7C, and 8 according to an embodiment ofthe present disclosure.

Referring to FIG. 9, at operation 901, the profile server may receive anevent request message from the terminal. The event request message mayspecify the type of an event requested by the terminal according to theabove-described embodiment of FIG. 4 and whether a remote profilemanagement function is currently activated/inactivated (on/off) in theterminal.

After performing operation 901 or if confirmation at operation 913 hasfailed, the profile server, at operation 903, may align events in theevent storage corresponding to the eUICC of the terminal that hastransmitted the event request message in the order of prioritiesaccording to the embodiment of FIG. 5 as described above.

At operation 905, the profile server confirms whether the type of theevent having the highest priority in the event storage coincides withthe type of the event requested by the terminal at operation 901.

If the confirmation procedure at operation 905 has failed or theconfirmation procedure at operation 909 has succeeded, the profileserver, at operation 907, confirms whether it is possible to transmitthe event corresponding to the event type requested by the terminalaccording to the embodiment of FIGS. 7A, 7B, and 7C as described abovemore preferentially than the event having the highest priority in theevent storage confirmed at operation 905.

If the confirmation procedure at operation 907 has succeeded, theprofile server, at operation 915, searches for the event having thehighest priority among the events that coincide with the event typerequested by the terminal in the event storage.

If the confirmation procedure at operation 905 has succeeded, or afterperforming of the operation 915, the profile server, at operation 909,confirms whether the corresponding event is a remote profile managementevent and whether the remote profile management function of the terminalis currently inactivated (off) in the event request message of theterminal received at operation 901.

If the confirmation procedure at operation 909 has failed, the profileserver extracts the corresponding event from the event storage accordingto the embodiment of FIGS. 7A, 7B, and 7C as described above, and addsthe corresponding event to the “current events” field.

After performing operation 911, the profile server, at operation 913,confirms whether bundle transmission of the corresponding event andother events is possible according to the embodiment of FIGS. 6A, 6B,6C, and 6D as described above.

If the confirmation procedure at operation 913 has failed, or theconfirmation procedure at operation 907 has failed, the profile server,at operation 917, configures a “next events” field according to theembodiment of FIG. 8 as described above.

After performing operation 917, the profile server, at operation 919,may transmit to the terminal an event response message composed of“current events” and “next events”. If transmission of the eventresponse message has failed, or if a reply to the processing failure ofthe event response message is received from the terminal hereafter, theprofile server may restore the event extraction operation in the eventstorage at operation 911 performed once or more.

FIG. 10 is a diagram illustrating an example of a procedure in which theterminal 230 successively receives one or more events from the profileserver 250 to perform the received events according to an embodiment ofthe present disclosure.

In this embodiment, it is assumed that a profile corresponding to anICCID1 is installed/activated in the terminal, a remote profilemanagement function of the terminal is activated (on), the event storageof the profile server is aligned in accordance with the order of eventregistration time, bundle transmission of the remote profile managementevent is impossible, but bundle transmission of the profile downloadevent is possible, preferential transmission of any event that deviatesfrom the priority is impossible, and the “next events” are configured todescribe only the event type of the event having the highest priority isdescribed in the event storage.

Referring to FIG. 10, at operation 1001, the terminal may receive acommand for “add profile” from a user.

At operation 1003, the terminal may perform TLS secure connection andmutual authentication procedure with the profile server, and may requesta profile download event from the profile server to suit the user'srequest according to the embodiment of FIG. 4 as described above.

At operation 1005, the profile server may notify the terminal that oneor more remote profile management events are in a standby state togetherwith the profile download event ICCID2 that is the event having thehighest priority in the event storage according to the variousembodiments of FIGS. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9 as describedabove.

At operation 1007, the terminal may install the profile ICCID2 inaccordance with the received profile download event.

At operation 1009, the terminal may transmit the performance result ofthe profile download event that has been completed (i.e., profileinstallation result (ICCID2 installation result)) to the profile server.

At operation 1011, the profile server may notify the terminal that theevent performance result has been successfully received. Further, at notonly operation 1005 but also operation 1011, the profile server maynotify the terminal of “next events” remaining in the event storage. Twotypes of messages to notify the “next events” are mutuallycomplementary, and the “next events” may be notified in both twomessages or in one of the two messages. If the “next events” arenotified in both the two messages, the “next events” lists included inthe two messages may differ from each other. As an example, if thepriorities of the events in the event storage of the profile server arechanged during performing of the operations 1007 to 1009 after themessage transmission at operation 1005, the “next events” list includedin the message at operation 1011 may be changed.

At operation 1013, the terminal may request again the profile server totransmit the event to be performed next time according to the “nextevents” list notified by the profile server at operations 1005 to 1011.If the TLS secure connection and mutual authentication procedure betweenthe terminal and the profile server at operation 1003 are stilleffective during transmission of the re-request message, the terminalmay omit the TLS secure connection and mutual authentication procedurewith the profile server. Further, if needed, the terminal may notify theuser that the event is to be requested from the profile server, and maytransmit an event request message to the profile server after obtaininga user consent. If the user does not consent, the terminal may end theprocedure without requesting an additional event. Further, if the eventto be performed next time in accordance with the “next events” list isthe remote profile management event, an identifier of the profile to bethe subject of the corresponding event is not clear, and thus the eventrequest type EventReqType may be set as the remote profile management,but the profile identifier may not be specified. A method not to specifythe profile identifier may transmit NULL character string, or may nottransmit the profile identifier field.

At operation 1015, the profile server may notify the terminal that oneor more remote profile management events are in a standby state togetherwith the remote profile management event (update ICCID1) that is theevent having the highest priority in the event storage.

At operation 1017, the terminal may manage the profile (change thecontents of the profile corresponding to the ICCID1) in accordance withthe received remote profile management event.

At operation 1019, the terminal may transmit to the profile server theperformance result of the remote profile management event that has beencompleted (i.e., profile change result (ICCID1 update result)).

At operation 1021, the profile server may notify the terminal that theevent performance result has been successfully received. Further, in thesame manner as in the procedure at operation 1011 as described above,the profile server may notify the terminal of the “next events”remaining in the event storage at not only operation 1015 but alsooperation 1021. For detailed explanation of the configuration of the“next events” list, explanation of the operation 1011 may be referredto.

At operation 1023, in the same manner as in the procedure at operation1013 as described above, the terminal may re-request the event to beperformed next time from the profile server in accordance with the “nextevents” list notified by the profile server at operations 1015 to 1021.Regarding the detailed explanation of the TLS and secure connection andthe user consent, explanation of the operation 1013 may be referred to.Further, if the event to be performed next time is the remote profilemanagement event in accordance with the “next events” list, anidentifier of the profile to be the subject of the corresponding eventis not clear, and thus the terminal may set the event request typeEventReqType to all events “ANY”, but may not specify the profileidentifier ProfileID. Regarding the method for specifying all events,the embodiment of FIG. 4 as described above may be referred to. Further,it could be easily understood that the subsequent procedure may beperformed through repetition of the operations 1001 to 1023 as describedabove.

FIG. 11 is a diagram illustrating an example of a procedure in which theterminal 230 successively receives one or more events from the profileserver 250 to perform the received events according to an embodiment ofthe present disclosure.

In this embodiment, it is assumed that a profile corresponding to anICCID1 is installed/activated in the terminal, a remote profilemanagement function of the terminal is activated (on), the event storageof the profile server is aligned in accordance with the order of eventregistration time, bundle transmission of the remote profile managementevent is possible, but bundle transmission of the profile download eventis impossible, preferential transmission of any event that deviates fromthe priority is impossible, and the “next events” are configured todescribe the type and the number of all events in the event storage.

Referring to FIG. 11, at operation 1101, the terminal may receive aspecific profile (in this embodiment, ICCID1) selected by the user, andmay receive a command for “refresh profile”.

At operation 1103, the terminal may perform TLS secure connection andmutual authentication procedure with the profile server, and may requesta remote profile management event from the profile server to suit theuser's request according to the embodiment of FIG. 4 as described above.

At operation 1105, the profile server may search for a profile downloadevent that is an event having the highest priority in the event storageaccording to the embodiment of FIGS. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and9 as described above, and since the corresponding event does notcoincide with the event type (remote profile management) requested bythe terminal and preferential transmission that deviates from thepriority is impossible, the profile server does not transfer any event,and the profile server may notify the terminal that one profile downloadevent and three remote profile management events are in a standby stateusing the “next events” list.

At operation 1107, the terminal may notify the user who has commandedthe refresh profile that the refresh profile is currently impossible andadd profile should be preferentially performed, and may obtain a userconsent in accordance with the received “next events” list. If the userdoes not consent, the terminal may end the procedure without additionaloperation.

At operation 1109, the terminal may re-request the profile server tosend “next events” list notified by the profile server at operation 1105and an event to be performed next time in accordance with the userconsent received at operation 1107. If one or more of the TLS secureconnection and the mutual authentication procedure between the terminaland the profile server at operation 1103 during transmission of there-request message have already been ended or a new event requestmessage should be discriminated by a new transaction ID on the policy ofthe profile server, the terminal may perform new TLS secure connectionand mutual authentication procedure with the profile server.

At operation 1111, the profile server may notify the terminal that threeremote profile management events are in a standby state using the “nextevents” list together with the profile download event ICCID2 that is theevent having the highest priority in the event storage according to thevarious embodiments of FIGS. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9 asdescribed above. In this embodiment, it is illustrated that the profilepackage is instantly transmitted in response to operation 1109. However,as exemplified in FIG. 2 as described above, profile metadata ispreferentially transmitted at operation 211, user consent to the profileinstallation is obtained again at operation 213, and a profile packageis transmitted to the terminal in the case where the terminal requeststhe profile package from the profile server at operation 215. In thiscase, an additional user consent may be integrated with the user consentat operation 1107.

At operation 1113, the terminal may install a profile ICCID2 inaccordance with the received profile download event (more specifically,profile package).

At operation 1115, the terminal may transmit the performance result ofthe profile download event that has been completed (i.e., profileinstallation result (ICCID2 installation result)) to the profile server.

At operation 1119, the profile server may notify the terminal that theevent performance result has been successfully received. Further,although not illustrated in the drawing, at operation 1119, the profileserver may repeat the “next events” list at operation 1111 in the samemanner as in the embodiment of FIG. 10 as described above.

At operation 1119, in the same manner as in the procedure at operation1109 as described above, the terminal may re-request the profile serverto send an event to be performed next time in accordance with the “nextevents” list notified by the profile server at operation 1117. Regardingthe detailed explanation of the TLS and secure connection and the userconsent, explanation of the operation 1109 may be referred to. Further,if the event to be performed next time is the remote profile managementevent in accordance with the “next events” list, an identifier of theprofile to be the subject of the corresponding event is not clear, andthus the terminal may set the event request type EventReqType to allevents “ANY”.

At operation 1121, the profile server may perform bundle transmission ofother remote profile management events Enable ICCID2 and Disable ICCID1together with the remote profile management event Update ICCID1 that isthe event having the highest priority in the event storage according tothe various embodiments of FIGS. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9 asdescribed above. Further, since there is no event in a standby state inthe event storage after the bundle transmission of the correspondingremote profile management events, the profile server may notify of“Nothing More” in the “next events” list. Notification of “Nothing More”in the “next events” list may be performed using a text as in thisembodiment, using NULL data, using omission of the “next events” listitself, or using notification of the residual event “0” with respect toall event types.

At operation 1123, the terminal may successively process the receivedremote profile management events. Further, it could be easily understoodthat the subsequent procedure may be performed through repetition of theoperations 1101 to 1123 as described above.

FIG. 12 is a diagram illustrating an example of a procedure in which theterminal 230 successively receives one or more events from the profileserver 250 to perform the received events according to an embodiment ofthe present disclosure.

In this embodiment, it is assumed that a profile corresponding to anICCID1 is installed/activated in the terminal, a remote profilemanagement function of the terminal is activated (on), the event storageof the profile server is aligned in accordance with the order of eventregistration time, bundle transmission of any event is impossible, butif the terminal requests, only the remote profile management event canbe transmitted more preferentially than the profile download event, andthe “next events” are configured to describe only the event type of theevent having the highest priority in the event storage.

Referring to FIG. 12, at operation 1201, the terminal may select aspecific profile (in this embodiment, ICCID1) from the user, and mayreceive a command for “refresh profile”.

At operation 1203, the terminal may perform TLS secure connection andmutual authentication procedure with the profile server, and may requesta remote profile management event from the profile server to suit theuser's request according to the embodiment of FIG. 4 as described above.

At operation 1205, the profile server may search for a profile downloadevent that is an event having the highest priority in the event storageaccording to the embodiment of FIGS. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and9 as described above, and since the corresponding event does notcoincide with the event type (remote profile management) requested bythe terminal, but the preferential transmission thereof, which deviatesfrom the priority, is possible, the event having the highest priority(in this embodiment, update ICCID1) among the events that suit the eventtype (remote profile management) requested by the terminal in the eventstorage can be preferentially transmitted. Further, the profile servermay notify the terminal that the profile download event that is theevent having the highest priority in the event storage is in a standbystate except for the corresponding event.

At operation 1207, the terminal may perform the received remote profilemanagement event. Thereafter, if needed, report of the performanceresult of the remote profile management event may be omitted.

At operation 1209, the terminal may notify the user who has commandedthe profile update that it is used to perform “add profile” after theprofile update according to the received “next events” list, and mayobtain the user's consent. If the user does not consent, the terminalmay end the procedure without any additional operation.

At operation 1211, the terminal may re-request the profile server tosend an event to be performed next time according to the “next events”list notified by the profile server at operation 1205. If one or more ofthe TLS secure connection and the mutual authentication procedurebetween the terminal and the profile server at operation 1203 duringtransmission of the re-request message have already been ended or a newevent request message should be discriminated by a new transaction ID onthe policy of the profile server, the terminal may perform new TLSsecure connection and mutual authentication procedure with the profileserver.

At operation 1213, the profile server may notify the terminal that tworemote profile management events are in a standby state using the “nextevents” list together with the profile download event ICCID2 that is theevent having the highest priority in the event storage according to thevarious embodiments of FIGS. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9 asdescribed above. In this embodiment, it is illustrated that a profilepackage is instantly transmitted in response to the operation 1211.However, as exemplified in FIG. 2 as described above, profile metadatais preferentially transmitted at operation 211, a user consent to theprofile installation is obtained again at operation 213, and a profilepackage is transmitted to the terminal in the case where the terminalrequests the profile package from the profile server at operation 215.In this case, an additional user consent may be integrated with the userconsent at operation 1209.

At operation 1215, the terminal may install a profile ICCID2 inaccordance with the received profile download event (more specifically,profile package).

At operation 1217, the terminal may transmit the performance result ofthe profile download event that has been completed (i.e., profileinstallation result (ICCID2 installation result)) to the profile server.

At operation 1219, the profile server may notify the terminal that theevent performance result has been successfully received. Further,although not illustrated in the drawing, at operation 1219, the profileserver may repeat the “next events” list at operation 1113 in the samemanner as in the embodiment of FIG. 10 as described above.

At operation 1221, in the same manner as in the procedure at operation1211 as described above, the terminal may re-request the profile serverto send an event to be performed next time in accordance with the “nextevents” list notified by the profile server at operations 1213 to 1219.Regarding the detailed explanation of the TLS and secure connection andthe user consent, explanation of the operation 11211 may be referred to.Further, if the event to be performed next time is the remote profilemanagement event in accordance with the “next events” list, anidentifier of the profile to be the subject of the corresponding eventis not clear, and thus the terminal may set the event request typeEventReqType to all events “ANY”.

At operation 1223, the profile server may notify the terminal that theremote profile management event is in a standby state suing the “nextevents” list together with the remote profile management event (enableICCID2) that is the event having the highest priority in the eventstorage according to the various embodiments of FIGS. 6A, 6B, 6C, 6D,7A, 7B, 7C, 8, and 9 as described above.

At operation 1225, the terminal may manage the profile (activate ICCID2)in accordance with the received remote profile management event.Further, the subsequent procedure may be performed through repetition ofthe operations 1201 to 1225 as described above.

FIG. 13 is a diagram illustrating a procedure in which a terminal 230requests a “profile download” from a profile server 250 and receives aresponse to the request in the case of installing a profile through theprofile server according to an embodiment of the present disclosure.

Referring to FIG. 13, at operation 1301, the terminal 230 may transmit acertain character string “Challenge” to the profile server 250.Communication at operation 1301 may be protected through HTTPS to TLSsecure connections. At operation 1303, the profile server 250 maytransmit to the terminal 230 a certain character string “Challenge”together with a signature of a server. At operation 1305, the terminal230 may transmit a terminal authentication request message to theprofile server 250. Specifically, the terminal 230 may transmit to theprofile server 250 information on the type (OperationType) of a specificevent requested together with the signature of the terminal 230 usingthe terminal authentication request message. In this embodiment,explanation will be made with respect to a case where a profile is in astandby state in the event storage 270 of the profile server and theterminal requests profile download (Profile DL). At the operations 1303to 1305, the message exchange procedure between the terminal 230 and theprofile server 250 may be called a mutual authentication procedure. Atoperation 1307, the profile server 250 may transmit a terminalauthentication response message to the terminal 230. Specifically, asrequested by the terminal 230 at operation 1305, the profile server 250may send to the terminal 230 the terminal authentication responsemessage including profile metadata and a one-time public key aspreparation for the profile download. The profile metadata may includeinformation on the name of a service provider, a logo set by the serviceprovider, and a charging system. At operation 1309, the terminal 230 mayreceive an input of an end user consent to the profile installationbased on the profile metadata received at operation 1307. If the userconsents to this, the terminal, at operation 1311, may send the one-timepublic key to the profile server 250. At operation 1313, the terminal230 and the profile server 250 may generate a session key throughcombination of a one-time public key mutually exchanged at operations1307 to 1311 with a one-time private key corresponding to the publickey. At operation 1315, the profile server 250 may send a profilepackage encrypted using the session key generated at operation 1313 tothe terminal 230 in reply. Thereafter, at operation 1317, the terminal230 may decrypt and install the encrypted profile package.

As compared with a remote profile management procedure to be describedlater, the profile download procedure, as described above at operations1311 to 1315, additionally utilizes one message exchange between theterminal 230 and the profile server 250 in order to receive the profilepackage used for actual profile installation.

FIG. 14 is a diagram illustrating a procedure in which a terminal 230requests a “remote profile management” from a profile server 250 andreceives a response to the request in the case of performing the remotemanagement through the profile server according to an embodiment of thepresent disclosure.

Referring to FIG. 14, at operation 1401, the terminal 230 may transmit acertain character string “Challenge” to the profile server 250.Communication at operation 1401 may be protected through HTTPS to TLSsecure connections. At operation 1403, the profile server 250 maytransmit to the terminal 230 a certain character string “Challenge”together with the signature of the server. At operation 1405, theterminal 230 may request from the profile server 250 the type(OperationType) of a specific event together with the signature of theterminal. In this embodiment, explanation will be made with respect to acase where a remote management command is in a standby state in theevent storage 270 of the profile server and the terminal 230 requestsRPM. At the operations 1403 to 1405, the message exchange procedurebetween the terminal 230 and the profile server 250 may be called amutual authentication procedure. At operation 1407, the profile server250 may transmit to the terminal 230 a package (RPM command package)including a remote profile management command as requested at operation1405. At operation 1409, the terminal 230 may receive an input of an enduser consent to the profile management based on the remote profilemanagement received at operation 1407. If the user consents to this, theterminal 230, at operation 1411, may perform a remote profile managementcommand.

In the remote profile management procedure, the terminal 230 can receiveall remote profile management commands at operation 1407, and ascompared with the profile download procedure as described above withreference to FIG. 13, one message exchange between the terminal 230 andthe profile server 250 corresponding to operations 1311 to 1315 of FIG.13 is not additionally required.

FIG. 15 is a diagram illustrating a procedure in which a terminal 230requests all types of events from a profile server 250 and receives aresponse to the request in the case of installing two profiles throughthe profile server and performing twice remote management according toan embodiment of the present disclosure.

Referring to FIG. 15, at operation 1501, the terminal 230 may transmit acertain character string “Challenge” to the profile server 250.Communication at operation 1501 may be protected through HTTPS to TLSsecure connections. At operation 1503, the profile server 250 maytransmit to the terminal 230 a certain character string “Challenge”together with the signature of the server. At operation 1505, theterminal 230 may request from the profile server 250 the type(OperationType) of a specific event together with the signature of theterminal. In this embodiment, explanation will be made with respect to acase where two remote management commands and two profiles are in astandby state in the event storage 270 of the profile server and theterminal 230 requests all types (ALL). At the operations 1503 to 1505,the message exchange procedure between the terminal 230 and the profileserver 250 may be called a mutual authentication procedure. At operation1507, the profile server 250 may simultaneously transmit remote profilemanagement 1, profile metadata 1, remote profile management 2, andprofile metadata 2 as requested by the terminal 230 at operation 1505.At operation 1509, the terminal 230 may receive an input of an end userconsent to the profile management and installation based on the remoteprofile management through the profile metadata received at operation1507.

After operation 1509, if the user consents, the terminal 230 may performremote profile management and profile installation procedure. In thiscase, the remote profile management (remote profile management 1 andremote profile management 2) can be performed just after operation 1509,whereas the profile installation (profile metadata 1 and profilemetadata 2) can be performed to secure a profile package by additionallyperforming one message exchange between the terminal 230 and the profileserver 250 as described above at operations 1311 to 1355 of FIG. 13 foreach profile installation. A detailed scheme for the terminal 230 tosuccessively perform the remote profile management and the profileinstallation will be described in detail with reference to FIGS. 16 and17.

In addition, respective profile metadata and remote profile managementdata at operation 1507 accompany the signature of the profile server 250for the terminal 230 to verify data integrity. In this case, if themethods for generating the signature for the profile metadata and thesignature for the remote profile management data (e.g., digitalsignature algorithm and digital certificate type for signature) aredifferent from each other, the profile server 250 may support theterminal 230 to easily verify the signature and process the respectivedata through proper adjustment of signature generation and datadeployment. A method for the profile server 250 to generate a digitalsignature and deploy data will be described in detail with reference toFIGS. 18 to 21.

FIG. 16 is a diagram illustrating a method for a terminal 230 tosuccessively process events after preferentially securing data for allevents according to an embodiment of the present disclosure.

Referring to FIG. 16, at operation 1601, the terminal 230 and theprofile server 250 may perform mutual authentication. Regarding themutual authentication and an operation request message of the terminal230, explanations at operations 1503 to 1506 of FIG. 15 may be referredto. At operation 1603, the profile server 250 may simultaneouslytransmit remote profile management 1, profile metadata 1, remote profilemanagement 2, and profile metadata 2. At operation 1605, the terminal230 may receive an input of an end user consent to the remote profilemanagement and installation based on the remote profile management andthe profile metadata received at operation 1603. If the user consents tothis, the terminal 230, at operations 1607 to 1609, may request profilepackage 1 and profile package 2 corresponding to the profile metadata 1and profile metadata 2, and may receive them from the profile server250. Thereafter, in accordance with the data processing order specifiedby the profile server 250 at operation 1603, the terminal 230 mayperform the remote profile management 1 at operation 1611, install theprofile package 1 at operation 1613, perform the remote profilemanagement 2 at operation 1615, and install the profile package 2 atoperation 1617.

In the procedure as described above, the terminal 230, at operation 1607to 1609, may collectively secure data (i.e., profile package for theprofile installation) used to process all the types of events receivedat operation 1603, and may perform the remote profile management andprofile installation in accordance with the data processing orderspecified by the profile server 250 at operation 1603.

FIG. 17 is a diagram illustrating a method for a terminal 230 to secureand process data of respective events in the order of event receptionaccording to an embodiment of the present disclosure.

Referring to FIG. 17, at operation 1701, the terminal 230 and theprofile server 250 may perform mutual authentication. Regarding themutual authentication and an operation request message of the terminal230, explanations at operations 1503 to 1506 of FIG. 15 may be referredto. At operation 1703, the profile server 250 may simultaneouslytransmit remote profile management 1, profile metadata 1, remote profilemanagement 2, and profile metadata 2. At operation 1705, the terminal230 may receive an input of an end user consent to the remote profilemanagement and installation based on the remote profile management andthe profile metadata received at operation 1703. If the user consents tothis, the terminal 230, at operations 1707, may perform the remoteprofile management 1 in accordance with the data processing orderspecified by the profile server 250 at operation 1703, receive profilepackage 1 corresponding to the profile metadata 1 at operation 1709,install the profile package 1 at operation 1711, perform the remoteprofile management 2 at operation 1713, receive profile package 2corresponding to the profile metadata 2 at operation 1715, and installthe profile package 2 at operation 1717.

In the above-described procedure, with respect to the all types ofevents received at operation 1703, the terminal 230 may preferentiallyperform the remote profile management without securing additional data,and if needed, it may perform the profile installation throughadditional securing of the profile package from the profile server 250as at operation 1709 or 1715 in accordance with the data processingorder specified by the profile server 250 at operation 1703.

FIG. 18 is a diagram illustrating a method for a profile server 250 togenerate and attach a separate signature to respective remote profilemanagement and profile metadata when the profile server 250 transfersthe remote profile management and profile metadata with respect to amessage of the profile server 250 at operation 1603 of FIG. 16 tooperation 1703 of FIG. 17 according to an embodiment of the presentdisclosure.

Referring to FIG. 18, the profile server 250 may generate digitalsignatures 1803 and 1811 with respect to remote profile management 1data 1801 and remote profile management 2 data 1809. Further, theprofile server 250 may generate digital signatures 1807 and 1815 withrespect to profile metadata 1 data 1805 and profile metadata 2 data1813. In this case, even if the profile server 250 does not specify thedata processing order, the terminal 230 may process the data in theorder of reception of the data from the profile server 250. In thisembodiment, the terminal 230 may process the data in the order of theremote profile management 1, profile metadata 1, remote profilemanagement 2, and profile metadata 2.

In the above-described configuration, each data is accompanied with aseparately discriminated signature, and thus it is advantageous that theprofile server 250 variously use algorithms and digital certificatetypes used to generate signatures for the respective data.

FIG. 19 is a diagram illustrating a method for a profile server 250 togenerate and attach a separate signature to respective remote profilemanagement and profile metadata and to specify the data processing orderwhen the profile server 250 transfers the remote profile management andprofile metadata with respect to a message of the profile server 250 atoperation 1603 of FIG. 16 to operation 1703 of FIG. 17 according to anembodiment of the present disclosure.

Referring to FIG. 19, the profile server 250 may generate digitalsignatures 1903 and 1911 with respect to remote profile management 1data 1901 and remote profile management 2 data 1909. Further, theprofile server 250 may generate digital signatures 1907 and 1915 withrespect to profile metadata 1 data 1905 and profile metadata 2 data1913. In addition, the profile server 250 may specify the dataprocessing order. As an example, in this embodiment for transmittingfour pieces of data, the profile server 250 may specify the processingorder of the data in a manner that among the four pieces of data, remoteprofile management 1 data 1901 is specified as the first one (¼),profile metadata 1 data 1905 is the second one ( 2/4), remote profilemanagement 2 data 1909 is the third (¾), and profile metadata 2 data1913 is the fourth (4/4).

In the above-described configuration, each data is accompanied with aseparately discriminated signature, and thus it is advantageous that theprofile server 250 variously use algorithms and digital certificatetypes used to generate signatures for the respective data. Further,since each data separately specifies the processing order, it isadvantageous that the profile server 250 can freely adjust the datatransmission order. In this case, this embodiment in which the profileserver 250 specifies the data processing order is not limited to FIG.19, and the data processing order may be specified even in theembodiment of FIG. 18 in which data is processed in the order of theirreception.

FIG. 20 is a diagram illustrating a method for a profile server 250 togenerate and attach a common signature to a part of each remote profilemanagement and profile metadata when the profile server 250 transfersthe remote profile management and profile metadata with respect to amessage of the profile server 250 at operation 1603 of FIG. 16 tooperation 1703 of FIG. 17 according to an embodiment of the presentdisclosure.

Referring to FIG. 20, the profile server 250 may generate a digitalsignature (i.e., common signature) 2011 with respect to the whole ofremote profile management 1 data 2001 and remote profile management 2data 2009. Further, the profile server 250 may generate a digitalsignature (i.e., common signature) 2015 with respect to the whole ofprofile metadata 1 data 2005 and profile metadata 2 data 2013. In thiscase, even if the profile server 250 does not specify the dataprocessing order, the terminal 230 may process the data in the order ofreception of the data from the profile server 250. In this embodiment,the terminal 230 may process the data in the order of the remote profilemanagement 1, profile metadata 1, remote profile management 2, andprofile metadata 2.

In the above-described configuration, it is to be noted that data forwhich the profile server 250 generates the common signature is notlimited to the same types of data. For example, although FIG. 20illustrates a case where the common signatures are generated throughseparation of the remote profile management and profile metadata, theprofile server 250 may generate the common signature with respect to thedata for which the same signature generation method (i.e., signaturegeneration algorithm and digital certificate) is used. In theabove-described configuration, since the signature can be omitted withrespect to the data sharing the signature, the amount of datatransmitted from the profile server 250 to the terminal 230 can bereduced. In the configuration of FIG. 20, the terminal 230 separatelygathers data becoming the subject of signature in order to verify thesignature after receiving the whole data of the profile server 250. Inthis embodiment, in order to verify the signature 2011, the terminal 230should selectively gather remote profile management 1 data 2001 firstlyreceived and remote profile management 2 data 2009 thirdly received, andin order to verify the signature 2015, the terminal 230 shouldselectively gather profile metadata 1 data 2005 secondarily received andprofile metadata 2 data 2013 fourthly received.

FIG. 21 is a diagram illustrating a method for a profile server 250 togenerate and attach a common signature to a part of each remote profilemanagement and profile metadata and to specify the data processing orderwhen the profile server 250 transfers the remote profile management andprofile metadata with respect to a message of the profile server 250 atoperation 1603 of FIG. 16 to operation 1703 of FIG. 17 according to anembodiment of the present disclosure.

Referring to FIG. 21, the profile server 250 may generate a digitalsignature (i.e., common signature) 2111 with respect to the whole ofremote profile management 1 data 2101 and remote profile management 2data 2109. Further, the profile server 250 may generate a digitalsignature (i.e., common signature) 2115 with respect to the whole ofprofile metadata 1 data 2105 and profile metadata 2 data 2113. Inaddition, the profile server 250 may specify the data processing order.As an example, in this embodiment for transmitting four pieces of data,the profile server 250 may specify the processing order of the data in amanner that among the four pieces of data, remote profile management 1data 2101 is specified as the first one (¼), profile metadata 1 data2105 is the second one ( 2/4), remote profile management 2 data 2109 isthe third (¾), and profile metadata 2 data 2113 is the fourth (4/4).

In the same manner as the case of FIG. 20, in the configuration of FIG.21, it is to be noted that data for which the profile server 250generates the common signature is not limited to the same types of data.In the above-described configuration, since the signature can be omittedwith respect to the data sharing the signature, the amount of datatransmitted from the profile server 250 to the terminal 230 can bereduced. Further, since the data separately specify the processingorder, the profile server 250 has the advantage that it can freelyadjust the data transmission order. For example, in order to remove aprocedure in which the terminal 230 selectively gather data forsignature verification in the embodiment of FIG. 20, the profile server250 may deploy the remote profile management 1 data 2101 and the remoteprofile management 2 data 2109 that share the signature 2111 just beforethe signature 2111, and may deploy the profile metadata 1 data 2105 andthe profile metadata 2 data 2113 that share the signature 2115 justbefore the signature 2115. In this case, the terminal 230 may processthe data in the order of the remote profile management 1, profilemetadata 1, remote profile management 2, and profile metadata 2, whichis the data processing order specified by the profile server 250 afterthe authentication of the signatures 2111 and 2115.

It is to be noted that the signature generation and data deploymentvarious embodiments of FIGS. 18 to 21 may be used in parallel to theprocedures of FIGS. 16 and 17. In this case, the procedure of verifyingthe respective signatures of FIGS. 18 to 21 may be selectively performedat a time in the procedures of FIGS. 16 and 17. Parts of the detailedembodiments are as follows, but are not limited to the followingembodiments. The verification procedure may be performed at a time whenthe signature verification is necessary.

FIG. 22 is a diagram illustrating an embodiment in which the signaturegeneration and data deployment method of FIG. 18 is used in theprocedure of FIG. 17 according to an embodiment of the presentdisclosure.

In this case, explanation of the procedure as described above withreference to FIGS. 17 and 18 and the reference numerals will be omitted,and it is assumed that the terminal 230 receives a message of the type,such as 2290, from the profile server 250 at operation 2201. Theterminal 230 may receive an end user consent at operation 2203, verify asignature at operation 2205, perform remote profile management 1 atoperation 2207, verify a signature at operation 2209, receive profilepackage 1 corresponding to profile metadata 1 at operation 2211, installthe profile package 1 at operation 2213, verify a signature at operation2215, perform remote profile management 2 at operation 2217, verify asignature at operation 2219, receive profile package 2 corresponding toprofile metadata 2 at operation 2221, and install the profile package 2at operation 2223.

FIG. 23 is a diagram illustrating another embodiment in which thesignature generation and data deployment method of FIG. 18 is used inthe procedure of FIG. 16 according to an embodiment of the presentdisclosure.

In this case, explanation of the procedure as described above withreference to FIGS. 16 and 18 and the reference numerals will be omitted,and it is assumed that the terminal 230 receives a message of the type,such as 2390, from the profile server 250 at operation 2301. Theterminal 230 may receive an end user consent at operation 2303, verify asignature at operation 2305, receive profile package 1 corresponding toprofile metadata 1 at operation 2307, verify a signature at operation2309, receive profile package 2 corresponding to profile metadata 2 atoperation 2311, verify a signature at operation 2313, perform remoteprofile management 1 at operation 2315, verify a signature at operation2313, perform remote profile management 1 at operation 2315, installprofile package 1 at operation 2317, verify a signature at operation2319, perform remote profile management 2 at operation 2321, and installprofile package 2 at operation 2323.

As described above, since verification of the signature for the datareceived by the terminal 230 may be performed by the terminal 230 at atime after the data is received, it may be performed before theprocedure of receiving an input of the end user consent. As an example,although not separately illustrated, in the case of using the signaturegeneration and data deployment method of FIG. 21 in the procedure ofFIG. 16, the terminal 230 may verify signatures 2111 and 2115 of FIG. 21after operation 1603 of FIG. 16, and may perform operation 1605 of FIG.16 and the subsequent operations.

As another example, although not separately illustrated, in the case ofusing the signature generation and data deployment method of FIG. 19 inthe procedure of FIG. 17, the terminal 230 may verify a signature 1903of FIG. 19, perform operation 1707 of FIG. 17, verify a signature 1907of FIG. 19, perform operations 1709 to 1711 of FIG. 17, verify asignature 1911 of FIG. 19, perform operation of 1713 of FIG. 17, verifya signature 815 of FIG. 19, and perform operations 1715 to 1717 of FIG.17.

FIGS. 24A, 24B, 25, and 26 illustrate various embodiments of a methodfor a terminal 230 to configure a user interface (UI) to receive aninput of an end user consent at operation 1605 or 1705 in the procedureof FIGS. 16 and 17 according to an embodiment of the present disclosure.

FIG. 27 is a diagram illustrating the operation of a terminal inaccordance with a time series flow according to an embodiment of thepresent disclosure.

Referring to FIGS. 24A, 24B, 25, and 26, it is assumed that data ofremote profile management1 2710, profile metadata1 2730, remote profilemanagement2 2750, and profile metadata2 2770 as illustrated in FIG. 27is received. It is also assumed that profile0 is installed and activatedin the terminal 230, the remote profile management1 2710 includes remotecommands of profile0 update 2711 and profile0 inactivation 2713, theprofile metadata1 2730 includes data for profile1 installation 2731, theremote profile management2 2750 includes remote commands of profile1update 2751, profile1 activation 2753, and profile0 deletion 2755, andthe profile metadata2 2770 includes data for profile2 installation 2771.

Referring to FIGS. 24A and 24B, if the terminal 230 receives data as inFIG. 27, it may output a user interface in the form as indicated by 2401of FIG. 24A or 2403 of FIG. 24B to the user. In messages 2401 and 2403,the terminal 230 may obtain a user consent by successively outputtingall procedures included in the data of FIG. 27. The order of outputtingthe respective procedures may follow the order in which the terminalreceives the respective procedures or the order in which the terminal230 will process the respective procedures. The consent to therespective procedures may employ individual user's checking as indicatedby 2401, or user's consent for integrating the whole as indicated by2403. Further, although not separately illustrated in FIGS. 24A and 24B,the terminal 230 may additionally display a service provider's name,logo, and service fees with respect to the profile that is the subjectof the respective procedures, or may additionally output a userinterface for receiving an input of a separate password or personalidentification number (PIN) set by the user or the service provider.

Referring to FIG. 25, if the terminal 230 receives data as in FIG. 27,it may output a user interface in the form as indicated by 2501 to theuser. In a message 2501, the terminal 230 may obtain a user consent byclassifying the procedures included in the data of FIG. 27 by profilesthat are the subject of the respective procedures to obtain a userconsent. Further, although not separately illustrated in FIG. 25, in thesame manner as the message 1301 of FIGS. 24A and 24B, the terminal 230may request individual user consent to sets of procedures classified byprofiles. Further, although not separately illustrated in FIG. 25, theterminal may additionally display a service provider's name, logo, andservice fees with respect to the profile that is the subject of therespective procedures, or may additionally output a user interface forreceiving an input of a separate password or PIN set by the user or theservice provider.

Referring to FIG. 26, if the terminal 230 receives data as in FIG. 27,it may output a user interface in the form as indicated by 2601 to theuser. In a message 2601, the terminal 230 may obtain a user consent byclassifying and outputting the procedures included in the data of FIG.27 by types of the respective procedures to obtain a user consent.Further, although not separately illustrated in FIG. 26, in the samemanner as the message 2401 of FIGS. 24A and 24B, the terminal 230 mayrequest individual user consent to sets of procedures classified bytypes. Further, although not separately illustrated in FIG. 26, theterminal may additionally display a service provider's name, logo, andservice fees with respect to the profile that is the subject of therespective procedures, or may additionally output a user interface forreceiving an input of a separate password or PIN set by the user or theservice provider.

It is to be noted that the user interfaces corresponding to FIGS. 24A,24B, 25, and 26 may be applied to all embodiments to which FIGS. 16 and17 are applied as described above. Accordingly, the user interfacescorresponding to FIGS. 24A, 24B, 25, and 26 can be applied even to theprocedures of receiving the user consent at operations 2203 or 2303 inthe various embodiments of FIGS. 22 and 23.

FIG. 28 is a diagram illustrating the configuration of a terminalaccording to an embodiment of the present disclosure.

Referring to FIG. 28, a terminal 2800 may include a transceiver 2810 anda processor 2820. Further, the terminal 2800 may include a UICC 2830.The UICC 2830 may be inserted into the terminal 2800, or may be embeddedin the terminal 2800.

The transceiver 2810 may transmit and receive signals, information, anddata.

On the other hand, the processor 2820 may control the overall operationof the terminal 2800. According to an embodiment of the presentdisclosure as described above, the processor 2820 may control theoverall operation of the terminal 2800.

Further, the UICC 2830 may download a profile and install the downloadedprofile. In addition, the UICC 2830 may manage the profile. The UICC2830 may operate under the control of the processor 2820. Further, theUICC 2830 may include a processor or a processor for installing theprofile, or an application may be installed therein.

FIG. 29 is a diagram illustrating constituent elements of a server 2900according to an embodiment of the present disclosure. For example, theserver 2900 may be a profile server.

The server 2900 may include a transceiver 2910 and a processor 2920.

The transceiver 2910 may transmit and receive signals, information, anddata. For example, the transceiver 2910 may transmit a profile to theterminal.

On the other hand, the processor 2920 is a constituent element forcontrolling the overall operation of the server 2900. According to anembodiment of the present disclosure as described above, the processor2920 may control the overall operation of the server 2900.

In the detailed embodiments of the present disclosure as describedabove, constituent elements included in the present disclosure areexpressed in a singular form or in a plural form in accordance with theproposed detailed embodiments. However, the singular or pluralexpression is selected to suit the proposed situation for convenience inexplanation, and the present disclosure is not limited to singular orplural constituent elements. Even the constituent elements in a pluralexpression may be expressed in a singular form, and even the constituentelements in a singular expression may be expressed in a plural form.

While the present disclosure has been shown and described with referenceto various embodiments thereof, it will be understood by those skilledin the art that various changes in form and details may be made thereinwithout departing from the spirit and scope of the present disclosure asdefined by the appended claims and their equivalents.

What is claimed is:
 1. A method performed by a terminal in a wirelesscommunication system, the method comprising: transmitting, to a server,a first message including first information associated with an operationtype requested by the terminal, the first information indicating aprofile download; receiving, from the server, a second message based onthe first information, the second message including first data for anoperation of the profile download and a signature of the server for thefirst data; transmitting, to the server, a third message includingsecond information associated with an operation type requested by theterminal, the second information indicating a remote profile management(RPM); and receiving, from the server, a fourth message based on thesecond information, the fourth message including second data for anoperation of the RPM and a signature of the server for the second data,wherein the second data comprises an RPM package and the RPM packageincludes an RPM command.
 2. The method of claim 1, wherein the firstdata comprises information indicating that the RPM package is pending,and wherein the second data further comprises information indicatingthat another RPM package is pending.
 3. The method of claim 1, whereinthe RPM package includes a plurality of RPM commands including the RPMcommand based on a priority of the plurality of RPM commands, andwherein the method further comprises: receiving a user input forexecuting the plurality of RPM commands included in the RPM package, theuser input being a combined input for the RPM package; and performing anoperation based on the user input.
 4. The method of claim 3, wherein, incase that more than one RPM commands are pending in the server, apriority of the more than one RPM commands is determined based on arequest of an operator.
 5. The method of claim 1, wherein, in case thatmore than one profile downloads are pending in the server, a priority ofthe more than one profile downloads is determined based on a request ofan operator.
 6. A method performed by a server in a wirelesscommunication system, the method comprising: receiving, from a terminal,a first message including first information associated with an operationtype requested by the terminal, the first information indicating aprofile download; transmitting, to the terminal, a second message basedon the first information, the second message including first data for anoperation of the profile download and a signature of the server for thefirst data; receiving, from the terminal, a third message includingsecond information associated with an operation type requested by theterminal, the second information indicating a remote profile management(RPM); and transmitting, to the terminal, a fourth message based on thesecond information, the fourth message including second data for anoperation of the RPM and a signature of the server for the second data,wherein the second data comprises an RPM package and the RPM packageincludes an RPM command.
 7. The method of claim 6, wherein the firstdata comprises information indicating that the RPM package is pending,and wherein the second data further comprises information indicatingthat another RPM package is pending.
 8. The method of claim 6, whereinthe RPM package includes a plurality of RPM commands including the RPMcommand based on a priority of the plurality of RPM commands, andwherein an operation corresponding to the plurality of RPM commandsincluded in the RPM package is performed based on a user input forexecuting the plurality of RPM commands, the user input being a combinedinput for the RPM package.
 9. The method of claim 8, wherein, in casethat more than one RPM commands are pending in the server, a priority ofthe more than one RPM commands is determined based on a request of anoperator.
 10. The method of claim 6, wherein, in case that more than oneprofile downloads are pending in the server, a priority of the more thanone profile downloads is determined based on a request of an operator.11. A terminal in a wireless communication system, the terminalcomprising: a transceiver; and a controller configured to: transmit, toa server via the transceiver, a first message including firstinformation associated with an operation type requested by the terminal,the first information indicating a profile download, receive, from theserver via the transceiver, a second message based on the firstinformation, the second message including first data for an operation ofthe profile download and a signature of the server for the first data,transmit, to the server via the transceiver, a third message includingsecond information associated with an operation type requested by theterminal, the second information indicating a remote profile management(RPM), and receive, from the server via the transceiver, a fourthmessage based on the second information, the fourth message includingsecond data for an operation of the RPM and a signature of the serverfor the second data, wherein the second data comprises an RPM packageand the RPM package includes an RPM command.
 12. The terminal of claim11, wherein the first data comprises information indicating that the RPMpackage is pending, and wherein the second data further comprisesinformation indicating that another RPM package is pending.
 13. Theterminal of claim 11, wherein the RPM package includes a plurality ofRPM commands including the RPM command based on a priority of theplurality of RPM commands, and wherein the controller is furtherconfigured to: receive a user input for executing the plurality of RPMcommands included in the RPM package, the user input being a combinedinput for the RPM package, and perform an operation based on the userinput.
 14. The terminal of claim 13, wherein, in case that more than oneRPM commands are pending in the server, a priority of the more than oneRPM commands is determined based on a request of an operator.
 15. Theterminal of claim 11, wherein, in case that more than one profiledownloads are pending in the server, a priority of the more than oneprofile downloads is determined based on a request of an operator.
 16. Aserver in a wireless communication system, the server comprising: atransceiver; and a controller configured to: receive, from a terminalvia the transceiver, a first message including first informationassociated with an operation type requested by the terminal, the firstinformation indicating a profile download, transmit, to the terminal viathe transceiver, a second message based on the first information, thesecond message including first data for an operation of the profiledownload and a signature of the server for the first data, receive, fromthe terminal via the transceiver, a third message including secondinformation associated with an operation type requested by the terminal,the second information indicating a remote profile management (RPM), andtransmit, to the terminal via the transceiver, a fourth message based onthe second information, the fourth message including second data for anoperation of the RPM and a signature of the server for the second data,wherein the second data comprises an RPM package and the RPM packageincludes an RPM command.
 17. The server of claim 16, wherein the firstdata comprises information indicating that the RPM package is pending,and wherein the second data further comprises information indicatingthat another RPM package is pending.
 18. The server of claim 16, whereinthe RPM package includes a plurality of RPM commands including the RPMcommand based on a priority of the plurality of RPM commands, andwherein an operation corresponding to the plurality of RPM commandsincluded in the RPM package is performed based on a user input forexecuting the plurality of RPM commands, the user input being a combinedinput for the RPM package.
 19. The server of claim 18, wherein, in casethat more than one RPM commands are pending in the server, a priority ofthe more than one RPM commands is determined based on a request of anoperator.
 20. The server of claim 16, wherein, in case that more thanone profile downloads are pending in the server, a priority of the morethan one profile downloads is determined based on a request of anoperator.